1. Field of the Invention
The current invention relates to data that is output by computer software applications, and, in particular, to data output to output files.
2. Description of the Related Art
Many software applications generate log files that document events generated or tracked by the corresponding software application. Typically, each entry in a log file corresponds to an event tracked or generated by a corresponding logging module of the corresponding logging application. Typically, logged events in the log file are separated by carriage-return and/or new-line characters so that each logged event is logged on a separate line of the log file. Other separator characters may be used instead.
A software application may contain multiple logging modules, where each logging module is adapted to add entries to a log file corresponding to the software application. It should be noted that the term “module” as used herein, unless otherwise indicated, can refer to a section of source code or to a corresponding entity in the compiled executable application. Typically, the log entries generated by a particular logging module follow a format specified in the source code for the logging module. Log entries by different logging modules in a software application may follow different formats since different logging modules can output different types of information.
The source code for a logging module in the C programming language, as well as related languages, typically includes a formatted-string output function such as fprintf. The formatted-string output function operates on a format string and corresponding parameters. The format string, also known as a format-control string, is a string that specifies the format of resultant log entries. The format string can include (1) fixed characters in the form of character-only strings and (2) type specifiers, which provide information for rendering the corresponding parameters in resultant log entries.
For example, the following line of source code may be found in a module for adding funds to an account: fprintf(LOG_FILE, “%d dollars added to account %s. The new account balance is %d dollars.”, nAdded, sAccount, nAccountBalance). Note that (i) LOG_FILE refers to the corresponding log file where the output will be written, (ii) the quoted string “%d . . . dollars” is the format string, and (iii) nAdded, sAccount, and nAccountBalance are the corresponding parameters. Assuming a sample value of $100 added to sample account 398421A for a new balance of $500, the resultant corresponding entry in the log file would be “100 dollars added to account 398421A. The new account balance is 500 dollars.” Assuming a sample value of $34 added to sample account 501388Z for a new balance of $379, the resultant corresponding entry in the log file would be “34 dollars added to account 501388Z. The new account balance is 379 dollars.”
A different module of the above sample application might contain the following line of source code: fprintf(LOG_FILE, “%d dollars withdrawn from account %s. The new account balance is %d dollars.”, nwithdrawn, sAccount, nAccountBalance). A sample corresponding log entry can be “60 dollars withdrawn from account 398421A. The new account balance is 440 dollars.”
It may be useful in analyzing a log file to be able to correlate a particular log entry to the source code module that generated the particular log entry. Presently, this can be done by modifying each formatted-string output function to include a line-number or similar identifier in its output so that each log entry indicates the source-code line number or module that generated that log entry.
However, there are problems with this prior-art approach. Modifying source code, especially where the source code is for a long and/or complex program, is a task often fraught with difficulties, such as maintaining consistency, avoiding creating new software bugs, and unexpected executable behavior due to the changes and/or requisite re-compilation. In addition, the source-code owner might not want the log file to provide information on the structure of the source code since the source code may be a trade secret of the source-code owner while log files generated by an executable application corresponding to the source code may be more widely accessible and could be used to reverse engineer the source code of the executable application. Furthermore, some applications generate log files for transmission over limited-bandwidth telecommunication devices where transmitting the additional log-file information required by the prior-art method would increase the transmission costs associated with transmitting the log file.